This post started out in life as an answer to a question about ‘backlog tooling’ on the LinkedIn ‘Lean & Agile’ group. Someone had given the culturally acceptable answer that the best solution is simple cards or post-it notes on a board or wall. I normally just let that pass because I don’t have a better solution to offer but this time, THIS happened:
I’m about to be intentionally provocative. We know that we are engaged in transforming a multidimensional network of business functions from one poorly understood and transient state to another, currently ill-defined, future state that we hope will emerge from the mist as we travel in it’s general direction. In organisations of any size, this change process is likely to run in parallel with other change programmes, some of them probably deliberately kept secret by people whose pay grade exceeds their ability to make rational judgements about the basis of who “needs to know”.
Amongst this chaos, the chosen tool of ‘the Agile Community’ is a single, 2-dimensional view of a ‘list of lists’, sometimes known as ‘a tree’ or ‘a star’, all of which are topologically equivalent representations of items’ states in the backlog of each Product development. Our best software tools are little more than a model of cards on a board.
Why do we expect the complex, dynamic agile change process to map any more adequately onto a tree of cards than it does onto a hierarchical management structure? Have we learned nothing from our mistakes of modelling within the limitations of the filing cabinet and the typewriter? Perhaps agilists don’t value tools because our tools aren’t fit for purpose.
If all you have is lists representing vague descriptions of changes between two mental models you hope your whole team all share, perhaps the limited nature of the backlog tool isn’t your biggest problem. The backlog items reference changes to an implicit model of roles and the objects in the business domain of your product. My advice is to make it explicit.
I have spent the last 2 evenings in Birmingham listening to talks by @diaryofscrum at @ScrumUK and @stevejpitchford at @bcsbrum about management and ‘Agile’ software development, which brought some of my own concerns into sharper focus, particularly about the Scrum framework. In many discussions with practitioners over the last couple of years, I’ve heard the following phrases:
“Agile is an adjective not a verb”
“Agile isn’t something you do, it’s something you are”
“Agile is a philosophy not a method”
“Agile isn’t a process”
Someone who ISN’T agile has to start somewhere. They typically need to DO something, to write software. Would we claim,”Scientific” is an adjective not a method? We wouldn’t, because it is both. The scientific method is a function which delivers what we call “scientific knowledge” as its value. If it didn’t, it would be pointless.
Managers are generally trying to get things done. Each team must agree its own Agile Operating Model (thanks to BCS’s ‘Agile Foundations’ book for that useful phrase.) What came out of the last couple of evenings was pragmatic application of philosophy. Many organisations take Scrum as a starting point, without realizing that “framework” is to be taken very literally. Scrum doesn’t paint the complete picture. It is (part of) a process to organize work. It says almost nothing about how to do that work. It is an alternative to writing a project plan “up-front”, when you know least.
An Agile Operating Model is a process which delivers a value, so it is a function. My scientific hypothesis is that it delivers valuable business function change, sometimes in the form of software. It is itself a business function. Agility has business functions as first class citizens. It doesn’t meet general expectations of a process because it can recursively self-modify. That doesn’t mean it isn’t one. As the kids say, “get you an agile function that can do both”.
I’ve tried to write this post before https://andywootton.wordpress.com/2015/07/07/software-life-cycle-part-2-from-craftsmanship-to-computational-science/
but I just answered a question about ‘software engineering’ on LinkedIn and I’m pleased with the brevity:
Agile software development is the application of the scientific method to understanding the requirements for a software product. Each iteration is an experiment to confirm a hypothesis of what the customer should really have wanted at the beginning, if they’d known what they know now.
I thought I’d said something about this but I can’t find it, so sorry if you’ve heard this before:
Professor Brian Cox turned to Dr. Hannah Fry and said, “You have 30 seconds to define ‘calculus'”.
She replied, “It’s the study of change.”
What we call “The IT Industry” deals almost exclusively with change. As a business analyst, I’ve worked in business process re-engineering which is the process of changing the processes which cause those changes. I’ve worked in agile software development teams that try to change software while the requirements for the target they’re travelling towards are changing, so the changes have to change.
I’ve met calculus in maths and physics but never in computer science. Why on earth aren’t computer scientists up to their necks in calculus?
This post refers to a technique often used in Agile software development, including within the Scrum framework. It is not an introductory text so not recommended for non-agilists.
‘user-stories’ are classified as: Must (do), Should (do), Could (do) and Won’t (do), known as: MoSCoW. User-stories are then usually prioritised by an integer representing value, which represents a calculation of return on investment, or benefit:cost.
Paul Oldfield, Chief Referee at LinkedIn ‘Agile & Lean Software Development’ group said:
I find a bit of a problem with MoSCoW – distinguishing between “Must have eventually” and “Must have in release 1”. Get beyond release 1 and a high value “should have” can be prioritized in front of a low value “must have”.
And then, a lot of the “must have in release 1” turn out not to be, if we look closely.
“If you want all these in release 1 you get nothing for 6 months.
Or you can get these in 2 weeks, those in 4 weeks… would you like that?”
I gave (a slightly worse version of) this reply:
I think MoSCoW is about ‘importance’ not ‘urgency’.
Urgency comes into the prioritisation choices when the benefit of the story is time sensitive.
Delivering benefit early starts summing value for longer, so total value delivered in the life-time of the product or service will be higher but now we’re talking about delivering a different absolute ‘spot value’. Putting it another way, value can be a function of time.
e.g. “If this isn’t ready in 2 weeks then we’ll be fined by the regulator” or
“We need this before the Summer Sale starts. If you miss that, it’s useless until Christmas.”
I didn’t know this before today. I’m sharing the idea in case it helps someone else or they can improve it and give me a copy. It’s how things worked before science had to make a profit.
I still see many people writing about adopting Lean and/or Agile software development. I can remember how difficult it was for my team to work out what ‘Agile’ was and I think it has got harder since, as growing popularity has drawn charlatans into the area. I see two main types of useful articles.
- What (theory) : “It’s a philosophy” articles which usually point first towards the different values of agile and lean practitioners. But you can’t “do” a philosophy, so we get:
- What (practice) : Methodology – the study of methods that embody the philosophies. Many will say that Lean & Agile are not processes but I disagree; I think they are ‘software development process’ change processes.
I’d like to try something different: WHY?
The old ways of planning engineering projects, used for building a tower block, didn’t work for software. We don’t know enough, with sufficient certainty at the beginning of development to design top-down and are rarely sufficiently constrained by physics to be forced to build bottom-up.
Unusually for computing, the words ‘lean’ and ‘agile’ have useful meanings.
Lean is about ‘travelling light’, by avoiding waste in your software development process. It uses observation and incremental changes of your current process, while you incrementally deliver business value via working software.
Agile is about doing only valuable work, being nimble and able to change direction, in response to changed requirements or better understanding. It recognises that there are very few completely stable business processes, so software developers need to identify changes that will have impact on the software under development and apply effort in a new direction.
I recommend that you consider both approaches, as they are complementary. Neither removes the need for appropriate engineering practices. We’re only throwing out hard-engineering stuff we packed but didn’t prove useful on a software journey. We throw out what we don’t need, to prevent the weight of unecessary baggage holding us back.