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… 😀
…for people that don’t (necessarily) care about careers!
As someone who has spent his entire working life since I left university doing things that are very hard to describe without saying “it’s sort of a combination of….”, I’ve always struggled a bit with “career planning” and the inevitable development discussions with my various managers – and they’ve probably struggled just as much with the conversations as I have.
The truth is that the roles I find interesting and challenging very often don’t exist but have be made by taking a role that does exist and then adding my own twist to it. Which means that discussions about developments are extremely difficult because there will almost always be elements of any standard role that I either don’t much care for or aren’t particularly qualified to do. I’ve never really thought of my work as a “career” but more as a series of assignment chosen based on what is available, what is interesting and what is challenging at any given moment – i.e. the “logical next step”. There was no “plan” to start out with and there still (mostly) isn’t now 10-12 years later.
Fortunately then to help alleviate this situation one day a few years ago inspiration struck and I came up with a model that I think better suits me and hopefully also many others with similar profiles. It’s basically just a two-axis grid which shows function or job type on one axis and level/type of involvement on the other. I used:
as my dimensions, but it could just as well be:
or something else that suits your context.
You then plot roughly where you see yourself being right now and then where you want to go. Not exactly rocket science, but very useful as a primer for discussions, because:
This model takes something that is absolute (what do you want to do?) and makes it relative (what do you want to do more of/less of compared to now?) and that makes a big difference because suddenly you can think of individual tasks or assignments rather than positions. It’s also a big difference for “the other side” (i.e. the manager) as you can spend less time discussing positions that may or may not exist let alone be available to fill, but instead give you as a manager an insight into what your team wants to do. This you can then use to “shuffle the deck” in the best possible way and try to give people tasks that they find challenging and inspiring, which in turn should improve development, satisfaction and retention all round.
It’s probably not a silver bullet for all situations, but use it wisely and it should make some of those hard discussions a bit easier. Feel free to leave a comment if you try it 😀