Of course this title has everyone asking “What in heck is an inch pebble?”, right? Well I was first introduced to this term by Johanna Rothman in an article she wrote about a hundred years ago. While I read it, and intuitively understood it, it didn’t at first occur to me that it was a comparative analogy. Until today…Continue Reading
Functional Architecture as a discipline has been brewing for a few years now. I have been a “functional architect” for a software application, and have also been involved in functional architecture review of enterprise software programs. I won’t claim to know what functional architecture means in any universal sense, but having done this work, and been in this role, I can describe some functional architecture principles that I know are helpful to making software more valuable in an enterprise context.
Functional architecture has several aspects. Continue Reading
Continuing down the path of understanding the differences between contemplation of project vs product as the center of our software universe.
Here are a few pithy aphorisms:
Agile thinkers focus on the product – and how we are intentionally adding value to a “software asset” and potentially how we manage our “portfolio” of software assets. Phase-Gated Delivery (some people call it waterfall) patterns allow us to “optimize” the work against the constraints – but do not allow us to optimize the value delivery in time. In fact, they push ALL the value delivery to the very end of the cycle. But in theory, because we can optimize the projects by minimizing the schedule and cost against a constant value output – the value can be had for less investment. Problems arise when – the actual value is realized over time (meaning the sooner the customer has access to a software capability, the sooner his actual costs go down or his profits go up).Continue Reading
One of the most useless project management conventions I have ever worked with is the status stoplight or RAG status. From a simplicity perspective, it is designed to convey a general state of the project. Green means things are “OK”. Amber means things aren’t that OK. Red means things are not OK at all. The convention is to get the attention of stakeholders when the status changes from green to amber to red. It is a beacon, or warning signal that something needs to change.
The other day, I read a tweet by @gnat (nat torkington), saying that fail fast as a mantra was misleading – because the objective was to learn, not to fail.
Actually when I exhort people to fail fast, the objective is to retire a risk. Sure, learning is important, but what is really important to the delivery of software is retiring risk. Either we know something will work, or we know it won’t work. Risk retired, the rest is just work.
What is necessary to fail is a set of success criteria. If it doesn’t meet all the criteria (at the same time), it fails. So when you send your team down the path of a POC or a Spike – with the exhortation to “fail fast”, you also need to provide them with some hard criteria to compare their results against. These criteria should give you an ability to predict whether your POC or Spike has really retired the risk, or whether you are simply kicking the can.
Recently I have had to look back on my career and remind myself what I have done. I am leading a challenging project, and at times it feels like I have team members and customers projecting their expectations for how the work will be executed. Sometimes amid the cacophony of voices, I have to remind myself that I am capable of bringing the team to consensus around strategic decisions. Continue Reading
In his Herding Cats blog, Glen Alleman, asks a very pertinent question. What is the definition of done? Well?
Done (Enterprise software delivery project) – when software capabilities have been delivered that support the business value proposition per the customer’s business capability requirements.
In our agility, we recognize that requirements are clarified by “emerging information”. That doesn’t mean that they “change”. When a requirement “changes”, it is effectively a new requirement. We often experience a case where the business value proposition is inadequately defined at the outset of the project. In this case, it is necessary for this requirement to be clarified by emerging information.
We also recognize that there may be different paths to deliver different software capabilities that support a particular business value proposition. Chosing a different path or delivering different software capabilities that support the same value proposition does not mean the requirements have changed, more likely that we are responding to emerging information.
I like to break requirements into business capability requirements and software capability requirements. Regardless of your project methodology you must contend with these facts:
Fact: Enterprise software projects are created to deliver some business value. The requirements should define both the value (business capabilities) and a path to deliver it (software capabilities). Requirements form the basis of the definition of done.
Assertion: If the business value does not change, there is not a new requirement.
Assertion: If during the delivery of the business value, we learn things about the domain, the technology, or the world external to the domain that alter the path to deliver the value – there is not a new requirement – but emergent information.
Assertion: How we manage the (the documentation of our understanding of) requirements is a method.
Fact: Some software projects are required to change course mid-stream. Sometimes the business value we initially intended to deliver is overturned by market pressure, financial impact, or a change in management or strategy.
Assertion: When the business value for a project changes, there is a new requirement.
Assertion: When the work done toward that value is abandoned, there is a loss.
Assertion: How we manage the (documentation and accounting for) change to requirements is a method.
—
Recognizing that there is a difference between allowing emerging information to clarify, influence, or stabilize the delivery of value and accounting for changes in the definition of the value stream for a project is key to understanding agile and how agile methods manage both cases.
—
In either case, the definition of done is when we have delivered working software capabilities that support the business value proposition(s) that have been “commissioned” by the customer.
In a number of posts over the last few months, Glen Alleman (Herding Cats) has been saying that Agile comparisons to “waterfall” or “predictive” are bogus, because the practices that they compare themselves to are simply BAD practices or anti-patterns in the domain of project management.
While I don’t disagree with Glen in the slightest, I want to start an argument about it. Just because they are bad practices, doesn’t mean they aren’t prevalent. There are many organizations with a software development life cycle (SDLC) that is waterfall-ish. And there are many organizations that have responded to regulations (Sarbanes-Oxley) by increasing the documentation requirements without thought to impact on software productivity or quality, that have effectively polluted their software development lifecycle with audit/regulatory oriented policies.
There are thousands of PMP certified morons who do not know (in practice) how to measure a project using any other tool than a gantt chart and a ruler. There are many software development managers who use project plans and process gates to indemnify themselves when things go wrong, who think that by mandating that requirements be “signed off” and requiring “change control” that they are immune to needing to deliver anything more than the minimum specified in the requirements.
There are thousands of software practitioners who have refused to give reasonable estimates because those estimates have been repeatedly weaponized by managers. (If I give you a stick and you hit me with it, next time I won’t give you the stick, or at least will wrap lots of padding around the it.) Many organizations have used “process” as an excuse to move much of the coding work “offshore” leaving ex-developers onshore in unacustomed roles as liasons, managers, project managers, analysts, and testers. They have imposed “process” in order to get work to “cheaper” resources, but have not invested in process maturity.
The thing about agile is that it appears to ALL to be a game changer. It makes it easy for us to drop all our anti-patterns at once. While I recognize that Glen is right – the dumb things that agilists say are similar to the dumb things that born again Christians say (“I don’t know how I would make it through the day with out Jeeesus.”) Agilist are often like ex-smokers – they can’t stop telling you how great they feel since they quit. Yeah – alot of the claims are based on comparisons to bad practices and known anti-patterns.
So Glen, to riff an old joke – why is using enterprise project management anti-patterns like hitting yourself in the head with a ball-peen hammer? Because it feels so good when I stop.
When your experience as a developer or project manager is fraught with project management anti-patterns, and you are a couple of pay-grades below the decision makers who are instituting said anti-patterns, what are your options?
a) Tell senior management that they don’t know their project management keister from a hole in the wall?
b) Find a new job at a better firm (oh wait – that assumes that there really is a better firm…)
c) Find some industry literature that shows a better way – a way that without faulting the folks who instituted the anti-patterns, can be adopted in small doses. A way that tries to put all members of a software development team on equal footing, creating collaborative realtionships rather than emnity.
So in the Dilbert world that most software projects are found in, – option C sounds like a huge winner. You really can’t fault the agilists whose primary exposure to project management practices has been in these environments from making those comparisons – that is their reality.
Planning a software development project is difficult. There are the typical issues: the changing face of technology, abstractions and generalizations, process maturity and resource competency. But none of this gets to the heart of why planning a software development project is difficult: because all of these things assume that the customer actually knows what they need and can articulate that need in a meaningful and comprehensible way; that the customer can describe the value that they want to get from the project when it is complete.
Depending on the methodology, analysts have constructed numerous abstractions to "organize" and "articulate" the value demanded by the customer. We call these "requirements". "features", "stories" – It really doesn't matter what you call them, as long as you recognize that they are the unit of value delivery around which you build your plan.
Your planning methodology (in conjunction with your software development methodology) must describe a way to turn these units of value into units of work. There are rules and assumptions that must be established about the content and structure of units of value that allow them to be converted into units of work. These assumptions and rule must be understood by analysts and customers who are defining the units of value, and by the technicians that are converting them into units of work. It is these rules and assumptions that allow your plan to accurately describe how you will deliver something of value to your customer, and allow you to communicate your progress towards the goal of that value delivery.
If you want to start somewhere to improve your software projects, start with defining the units of value, and the rules and assumptions necessary to convert them into units of work.