People tend to use the terms Sprint, Iteration, and Time box interchangeably. For the most part this is true, but there is some nuance:
Sprint is a term popularized by Mike Beedle and Ken Schwaber in creating the Scrum methodology. They chose the word because it implied a desire for fast pace. It’s not a death march (Yourdon), its a sprint.Continue Reading
Every programmer struggles with providing estimates. It is a universal truth of software development. Most of the time we go way too deep, try to be more precise than we have any reason to be. Many times we have fear driving our estimates – what if they are too big (will they cancel the project? or will they assign the work to someone else?) or worse, what if they are too small (will they fire me because I appear incompetent?).
Here are my top six tips for solving estimation challenges in software development projects:Continue Reading
Glen Alleman in his post How Long Should Tasks Be gets to the heart of an important issue. When planning, how long can you wait before you know that you are late.
In principle, it works like this – you don’t know you are late until you fail to complete a task on schedule. How late you are depends on the remaining work in the late task. How long can you wait to determine that a task is behind schedule? That depends on where you are on the project timeline and how much “margin” is remaining in the plan.
In practice there are other dependencies. Measurement frequency is important. The more frequently you measure progress against the plan, the smaller tasks increments you will naturally prefer. You want to see progress at every measurement cycle.Continue Reading
In my former post about progressive elaboration, I promised some “examples” from different domains of software development. This is the first of these. As I said before, progressive elaboration is about acknowledging that we can’t know everything we need to get to done before we start.
One of the difficulties of requirements elicitation is to maintain a consistent level of detail, both in documentation and in our conversation with practitioners, subject matter experts, and individual contributors. Another typical difficulty is understanding whether requirements are sufficient to begin some subsequent activity like design or coding.
While some methodologies have made recommendations, most merely call out the need. This leaves it up to the requirements analyst to build their own practice. In fact, most analysts do not subscribe to any specific methodology that they practice. I have often used these interview questions for analysts that I expect to elicit and organize requirements for software applications.Continue Reading
I’ll allow up front that I am not a huge advocate of TDD. Not because I think it is bad, its good. Not because I think it is hard, although it adds abstractions to the development process that are hard for some developers to grok. Not because I think it is a waste, because even though it adds time up front, it can save double on the back end. I am not a huge advocate of TDD, simply because it has the developers writing the tests.
Over years and years of software delivery experience, as a developer, as a tester, as a project manager, a business analyst, a manager I have observed one truism. Software developers cannot be trusted to understand the requirements deeply enough to test their own code. There are too many layers of abstraction in the way.
As Seymour Cray is reported to have said,
Progressive elaboration is one technique that can be applied to virtually any aspect of software development. In reality it is a simple analysis technique which revolves around the maxim: start with what you know.
In agile software development, we apply this to several activities: requirements, design, and planning.
Progressive elaboration starts with the notion, that you cannot know enough about a software system to get to “done”, before you start. Progressive elaboration is sort of a continuous bootstrap process for knowledge.
While agile proponents also talk about how they embrace change, that is not what progressive elaboration is for. Progressive elaboration is a means to get started before you know enough to get to done. It is a means to prevent knowledge gaps from impeding progress. It is a means of driving out information through completing work, rather than by theoretical analysis.Continue Reading
When you adopt agile practices, especially agile life cycle plans – it is really simple to have your project manager become the scrum-master, right? Isn’t that what everybody does? After all, it’s just swapping a gantt chart for a burn down chart, right?
It certainly is what all of the project managers do when their companies start to adopt agile life cycles – but is it the best thing, or even a good thing? Continue Reading
OH: (on twitter)
“Convinced. Everyone that says “agile doesn’t work” or even “agile doesn’t work for us” just doesn’t know what it means to be agile.”
I read this on Twitter over the weekend (12/17/11). It really got me fired up. Mind you, I am an avid agilist. The point is, that some situations are not particularly suited to derive benefit from agile practices. Continue Reading
Upgrade to the Human Operating System – BusinessWeek
I read this article, and it seemed to me to say for organizations in general, what Agile has done for software development teams. Moving from a command and control – process/factory model, to a model that allows/incents/expects humans to invent, analyze, innovate, figure out. Is it possible that we are finally ready to tranform organization structure from its industrial age roots into an information age – service orientation. How many organizations say “our people are our most valuable resource” – but act like they have FTE’s – (HR/Manager speak for “universal man widgets”).
I highly recommend that you evaluate every difficult thing that is on your plate, and decide whether it is lack of talent/skill/knowledge or simply lack of motivation that is getting in your way. I hate this evaluation, because it always comes out the same. Arrgh!
Seth’s Blog: The difference between management and leadership
This short post was a huge shot in the arm for me this week. Management is about constraints, leadership is about movement. Movement and constraint are opposing forces. Dang! Now that I am not in a staff management role (first time since ’04) this is much easier to see.
Stories, Epics and Themes | Mike Cohn’s Blog – Succeeding With Agile®
Mike Cohn is pretty much “the man” on user stories. I have had conversations with lots of agilists about stories epics and themes (story scope). What nobody (including Mike) really wants to get into is whether stories are about business capabilities or software capability. IMHO – when it comes to “requirements” for software – everything (not just agile) craps out on this divide. And it is a critical division because all the value is on one side, and all the work is on the other. Hmm. Never the less – I thought this was one of the best posts on story scope I have read in a long time.
Want to be strategic? Be competent first | Adventures in IT – InfoWorld
Provocative post about walking before you run. If you can’t execute, your strategy will not help.
Agile Complexification Inverter: What are the Principles?
I like this way of thinking – principles first, because it helps us stay out of “methodology” land. Too often, we are looking for a “prescription”, rather than ways of thinking that help us solve problems that are impeding our progress.
How to Change the World: What I Learned From Steve Jobs
Best bit: A players hire A+ players…. – Avoid the bozo explosion.
Herding Cats: Are We There Yet?
Project management 101 from Glen Alleman.