Got this in my LinkedIn feed today and had to repost it, because it’s brilliant(ly accurate) 😉
“Our mantra is MonkeyFirst. The idea is that if you want to get a monkey on a pedestal to recite Shakespeare, you start by training the monkey, not building the pedestal. Because training the monkey is the hard part – anyone can build a pedestal!
The problem is that most people start with the pedestal, because it’s what they know. And by building it, they can show early progress against a timeline. Unfortunately, building a pedestal really gets you nowhere. Unless you can actually train the monkey, working on the pedestal is just wasted effort.”
So, look at your projects and decide which parts of them are monkeys and which parts are pedestals…
No, I’m not talking about the agile manifesto, but the “principles” you can extract from the agile framework descriptions such as SAFe® or Dean Leffingwell’s book on agile software requirements which I recently finished. Here’s what I get:
1) Agile was made for the development of software as a product for sale to external customers.
If you want to use agile methods for developing software for use by internal customers, or – as many do – to implement software that you have acquired (whether custom-developed or off-the-shelf) from someone else, it’s definitely possible. However, you can’t use the principles and concepts blindly because they don’t always make 100% sense in those contexts so you have to be prepared to deviate – and the organisation has to understand when and why to deviate. There’s a very brief section in Leffingwell’s book (in the “Product Owner”) chapter, that deals with the challenges of owning the implementation stages as well, but it’s a bit too short to cover all the impacts.
2a) Agile doesn’t mean you can be super-flexible everywhere.
Basically, the agile methodology creates flexibility in some areas by being ultra-rigid in others. Just think about the daily stand-ups at precisely the same time and with the same fixed agenda or the preset sprint duration and the regular planning sessions and recurring demos. This trade-off has to be understood because it’s one of the cornerstones of the agile methodology and it’s one I mentioned previously as well.
2b) Agile doesn’t mean you don’t plan – just that you plan differently.
Being agile basically means you plan much more in certain areas to be able to plan less (or with a shorter horizon) in others. That means as long as you have a very strong (and very closely monitored) strategic plan, then you can make you tactical plan a bit more loose and your operational plan even more flexible. That’s good, because it empowers the organisation that executes the plan, to reach the goal even when the original road turns out to be impassable or just plain wrong, but it doesn’t mean that you can (or should) change direction on a whim.
3) Agile shouldn’t be used to define the problem/goal, but to define the best solution for an already agreed problem/goal.
Another classic misconception (IMO) is that if we do not know what we want, we can use agile to find out – I don’t agree with that. Because agile execution has a very short-term focus, if you do not understand the overarching goal of what you are trying to deliver, there is no guidance for a product manager/owner to follow and as a result you risk spending all of your budget on delivering “features” that together do not really form a whole.
Instead, you can use what I call a “gated agile” approach meaning that you do short-feedback “sprint”/”spike” iterations to investigate, align with stakeholders and test hypotheses as to what the problem could be, but keep strict evaluation “gates” where you stop and agree if you are still on the right track. This is similar in concept to the agile structure of “code it out” and using spikes to nail down hard problems or unknown issues, but the “stop and evaluate“ aspects are often overlooked or dismissed as “waterfall” thinking – it definitely isn’t!.
Once you have reached a stage where everyone then agrees on the problem, you can architect and develop the solution, break it down into epics/features/tasks and then execute on those using an agile approach without problems and with most of the initial risk of failure already mitigated.
4) Agile should be used with care on technologies that are new to the organization
This is sort of a variation of the first points, but if you do not understand the technology you are working with and what it can (and can’t) do for you, you’re very likely to fall into the traps of the first points on the list here. This problem goes up exponentially if you are not just developing but also implementing in the organisation – because if you think that development-related challenges of new technologies are tough, wait until you try adoption-related challenges (i.e. organisational resistance) to a new technology!
So, is it all complaining then? Did I not learn anything from reading the book? I did, but more of that in a second part/post 😀
Also, I will be attending an official SAFe® methodology course in a few weeks, so I look forward to seeing if I still make the same conclusions afterwards – and of course having a good discussion with some colleagues in the process.
”50% scope at 100% quality and 100% scope at 50% quality might have the same cost, but rarely the same value”
Not really a quote as such, more a conclusion on a discussion with a co-worker. Amazingly, not everyone gets this though…
”Beware of anyone who peddles simple solutions to complex problems”
Worth remembering, not only at work but also when reading the news or listening to people give advice on anything from diets to how to solve climate problems…
“Do you want to be better than everyone else at doing something – or do you want to do something that no one else can?”
Based on a recent discussion about personal development and performance with a (former) co-worker, we ended up at this question. I guess everyone should ask themselves this from time to time when evaluating your career and future job opportunities, new projects etc.
Personally, I’m definitely aiming for the latter category but of course others will have to judge my success 😉
”Some people strive to be punctual. Some people strive to be worth waiting for”
I know which one I’d rather be 😀
As mentioned in a previous post, I am now part of an organisation that is attempting to convert much of its IT development to an “agile” approach, more specifically by adopting the “Scaled Agile Framework” (SAFe®). Although I am not directly involved in this work I still see and hear enough to notice some patterns emerging.
The origins of agile are in development, i.e. where you basically turn requirements into code. This is more or less the same all over, but when you start scaling agile to cover bigger “organisations”, then suddenly there are a couple of different flavours to be considered.
If you develop software as a product to sell to others, either by putting it on the shelf or using a “made-to-order” approach, the objective is either to put the most appealing product on the shelf or most effectively and efficiently meeting the customer requirements. Once the product is done, that effectively concludes the exercise and your agile approach is therefore really “scaled agile product development”.
However, if you are an organisation that develops or implements software for internal use using agile, then you are effectively doing “scaled agile system implementation”, which is a slightly different flavor to the development one. It’s different because you are now responsible as an organisation for realising the business benefits of the solution and not just completing the product (in essence, outcome vs. output responsibility), and that means that new parameters/considerations start to creep in.
- How do we ensure usability of the solution over the entire life cycle?
- How do we cover compliance requirements, not just for the base product but also whatever is required for usage and maintenance of the solution over the entire life cycle?
- How do we cover user stories to deal specifically with upgrades and maintenance activities in our organisation? (and, just as importantly, how do we get those user stories prioritised during development?)
- And last but not least (actually, probably the opposite!) – how do we include organisation change management activities and user acceptance as part of the agile implementation cycle.
That is of course not to say that these points are not important when you develop software for sale, but they form a bigger part of the total cost/total value equation when the scope is a full implementation and usage cycle – and it’s becoming clear to me that much of the complexity in scaling agile are not in the development, but in the parts that follow being agile at scale…
“Don’t cling to a mistake just because you spent a long time making it”
One of my former colleagues had this on his desk – surprisingly useful (and much-needed) advice… 😀